PYTHON-6050 Build libbson 2.5.3 from source with Meson - #112

libbson 2.x's mlib/time_point.h needs POSIX feature-test macros
defined directly rather than detected, and bson_as_json() was removed
in favor of bson_as_json_with_opts().

- vendor.sh now diffs and reverts bsonjs/common/common-config.h the
  same way it already does for bsonjs/bson/config.h, instead of
  silently overwriting the hand-checked-in copy.
- MANIFEST.in now includes *.th files so the new mlib/vec.th template
  ships in the sdist.
- bsonjs.c uses bson_as_legacy_extended_json() instead of manually
  building bson_json_opts_t, matching the RELAXED/CANONICAL calls
  already in this function.

…g them

paths-ignore only filters results for interpreted languages or
build-mode: none — it doesn't apply when build-mode is manual/autobuild,
per GitHub's own docs, so it never excluded bsonjs/bson/*.c from the
c-cpp analysis despite listing them. .codeqlignore is likewise a no-op
here since it's only read by GitHub's Default Setup, which this repo
doesn't use.

CodeQL only extracts files the compiler is actually invoked on, so the
c-cpp job now compiles just bsonjs.c directly instead of running the
full `pip install -e .`, which also built every vendored .c file under
bsonjs/{bson,jsonsl,common}.

vendor.sh now deletes bson-bcon.c, common-md5.c, and common-thread.c
right after syncing them, so future vendor bumps keep them out
automatically instead of needing setup.py to filter them out of the
build every time. Their headers stay: bson.h includes bson-bcon.h, and
common-thread-private.h is a real dependency of bson-context.c and
common-b64.c.

setup.py's sources glob goes back to unfiltered, now that the files
it would have excluded no longer exist in the tree.

CI runners (especially Windows) can stall for 20+ minutes on the FetchContent
download of the mongo-c-driver tarball with no output. Download with hard
timeouts (TIMEOUT/INACTIVITY_TIMEOUT) and retries so a stall fails fast instead
of hanging the build. Also cache the release tarball via a setup-mongo-c-driver
action and feed it to CMake through BSONJS_MCD_TARBALL, so later runs skip the
download entirely.

The BSONJS_MCD_TARBALL override uses a Windows path with backslashes, which
broke the FetchContent subbuild's generated CMakeLists.txt (syntax error).
Convert it with file(TO_CMAKE_PATH) and only skip the download when the
normalized path actually exists.

Hardens the download so CI never silently falls back to the stalling codeload
endpoint mid-build. setup-mongo-c-driver now fails the job (set -euo pipefail +
test -s) if the release tarball can't be fetched within the retry/timeout
budget, and is wired into the dist.yml wheel build too so the host builds
(macOS/Windows) pre-fetch it. CMakeLists still prefers the pre-fetched archive;
the timeout-bounded download stays as a fallback for dist.yml Linux containers
and sdist/local builds, which can't run the action but don't stall on codeload.

GitHub does not stream the in-build CMake output until a job finishes, so a
stall is invisible. Add [bsonjs] phase markers (configure begin, archive source
+ size, download, FetchContent_MakeAvailable begin/done) with an elapsed counter
to CMakeLists, and log cache-vs-download in setup-mongo-c-driver. The next run's
log will show exactly which phase consumes the time on the hosted runner.

The pip build-isolation env (fresh venv + tmp dir re-installing
scikit-build-core/cmake/ninja each run) is a suspect for the slow Windows build.
Pre-install the build deps and build with --no-build-isolation, so the wheel
builds in the repository's own build/ dir. Verified on the Windows host: the
cp311-abi3 wheel builds in ~18s. Also guard the ccache stats step off Windows,
where ccache is no longer installed.

The ENABLE_MONGOC/ENABLE_SHARED/ENABLE_STATIC options were set AFTER
FetchContent_MakeAvailable, so they were never honored and mongo-c-driver
defaulted to building libmongoc (plus zlib, utf8proc, SASL, and the shared
variants) — ~300 C files instead of the ~30 for libbson. That is why the
GitHub-hosted Windows build stalls (a 10x MSVC workload) and why the Linux
dist wheel fails with "MONGODB-AWS requires a crypto library".

Move the options above the single MakeAvailable so the subproject configures
libbson-only, and pin the same defines in pyproject (cmake.define) so every
build path configures the same minimal build.

GitHub-hosted Windows real-time MSVC compilation is throttled by Defender,
which is the classic cause of 10-50x slowdowns. Exclude the checkout from
Defender scanning before the build. Combined with building only libbson, this
targets the residual slow compile on hosted runners.

Diagnostic: print whether cl/gcc are on PATH and which C compiler CMake picks,
so we can confirm the GitHub-hosted Windows runner is building with MSVC and
not MinGW-w64 gcc (which is preinstalled alongside Visual Studio).

Diagnosis: scikit-build-core uses Ninja, which picks the compiler from PATH.
On GitHub-hosted Windows `cl` is not on PATH and C:\\mingw64\\bin\\gcc is, so the
build was compiling with MinGW gcc (GNU 12.2.0), not MSVC — a different toolchain
that behaved unlike the box. Set up the MSVC dev environment (vcvars64 via
vswhere) before pip wheel so cl.exe is on PATH and scikit-build-core builds a
proper MSVC extension.

scikit-build-core's Ninja build picked MinGW gcc on Windows runners,
producing a GNU wheel instead of an MSVC one. Meson with --vsenv
forces the Visual Studio toolchain. The Meson build compiles libbson
from the vendored mongo-c-driver source and tags the module cp311-abi3.

error.c needs _XOPEN_SOURCE >= 700 or _GNU_SOURCE for strerror_l, so
use _GNU_SOURCE on non-Apple POSIX hosts. Windows extraction broke
because Git-bash tar reads the colon in a drive-letter path as a remote
host; extract with Python tarfile instead.

Meson 1.12 cannot parse the /showIncludes dependency prefix that the
windows-latest runner's new MSVC 19.51 (VS 2026) emits, so dep-prefix
detection aborts. windows-2022 provides VS 2022 (MSVC 17.x), which Meson
handles.

windows-2022 has no ccache preinstalled, so the setup-ccache action's
ccache --zero-stats step exits 127. ccache is a GNU/Clang launcher and is
not used by the MSVC/Meson Windows build, so don't set it up there.

libbson's bson-context.c calls gethostname, which needs ws2_32.lib on
Windows. A bare 'ws2_32' link arg made the MSVC linker look for
ws2_32.obj and fail with LNK1181; find_library resolves it correctly.

The Meson migration replaced CMakeLists.txt, so build docs and the
libbson bump helper now reference meson.build. Removes the leftover
BSONJS_MCD_TARBALL env var that Meson no longer reads.

Add scripts/fetch_mongo_c_driver.py, shared by the meson build, the CI
setup action, and CodeQL. It reads the version and SHA256 pin from
meson.build, so bump_libbson.py updates both and no caller hardcodes a
version.

meson.build fetches the pinned release when .mongo-c-driver/ is absent,
so an sdist can build itself. Correct the source-build wording, require
meson 1.3 for limited_api, and fix the stale CMake references.

meson-python cannot find the 32-bit Python headers in the 32-bit
cibuildwheel environment, so the win32 build fails. Restrict the Windows
build to AMD64 and note the dropped architecture in the changelog.

windows-2022 has no ccache preinstalled, so the setup-ccache action's
ccache --zero-stats step exits 127. ccache is a GNU/Clang launcher and is
not used by the MSVC/Meson Windows build, so don't set it up there. The
test workflow already guards this.

musl does not alias _GNU_SOURCE to _DEFAULT_SOURCE, so libbson's mlib
time_point.h fails its POSIX clock check and the musllinux aarch64 build
aborts. glibc aliases the two, which is why manylinux passes.

Also run the dist wheel matrix with fail-fast disabled so one failing
platform does not cancel the others.

libbson's error.c selects strerror_l only when _XOPEN_SOURCE >= 700. musl
does not derive that from _GNU_SOURCE, so the musllinux build falls back to
glibc-style strerror_r and fails to compile. glibc derives it, which is why
manylinux passes.

Meson's --vsenv activates only the x64 toolset, and its Python dependency
check rejects a 32-bit Python against an x64 compiler ("Need python for
x86_64, but found x86"), which is why the 64-bit-only workaround landed.
The dist workflow now runs a second cibuildwheel pass for x86 with the
x86 toolset exported first, so Meson skips its own activation and
detects the host as x86.